Technical Debt: Solutions to Put in Place Throughout Development

The same way a building that was built decades ago will alternately need new windows, structural adjustments or a fresh coat of paint, a digital solution must be proactively maintained to prevent it from degrading over time.

When this proactivity isn’t present, a technical debt starts to accumulate. This term is the sibling of the same expression in the financial sector: if a technical debt isn’t settled (corrected), it accumulates interest. These interests can take several forms: software rot, code refactoring, bugs… They can even pose important security risks or cause additional technical debts.

Because it’s fundamental to be proactive in the maintenance and the evolution of digital solutions, we have a complete team of versatile experts who can guarantee the continuation of our digital solutions: the Maintenance & Evolution Team. Today, members of this team share with us their knowledge and recommendations to limit and control the risks associated with technical debts.

According to this article, maintaining a digital solution represents 50 to 75% of total costs for a solution. In our experience and depending on the project and the year, the real costs of maintenance, namely system updates, will usually represent a total cost of 10 to 20% of the initial investment in the project. The evolution costs will differ in accordance with the business goals for each digital solution.

There are three types of maintenance:

• Corrective maintenance, to correct computer bugs;
• Evolving maintenance, to add new features to a piece of software;
• Performative maintenance, to improve a software’s maintainability.

Settling a technical debt usually concerns performative maintenance, which is a digital solution’s guarantee of durability.

There are several technical debt types that can be identified and prioritized with the SQALE method (Software Quality Assessment based on Lifecycle Expectations). This method is based on nine criteria: reusability, portability, security, usability, efficiency, alterability, reliability, and testability.

Here is a list of the most common technical debts:

• Big ball of mud: system or software missing a clear architecture. It might be advised to completely rewrite this type of software.
• Software erosion: gap between a software’s planned architecture and its implementation. A software system’s architecture doesn’t enable modifications, because continuous changes introduced in it made it impossible to maintain. In this case, we say the system is crystallized.
• Spaghetti code: code that is unstructured and difficult to maintain, which can be caused by several factors like changing requirements in a project, absent programming style rules or overengineered software.
• Code smell: although the term is subjective, it is considered a bad design or software implementation practice that generates flaws. Code smell can slow down the development of app or features, but it can also create future bugs.
• Antipattern: software design errors inherited from the software’s design phase caused by an absence or misuse of design patterns. These errors frequently cause an excessively slow software, high realization or maintenance costs, abnormal behaviour, and bugs.

“A technical debt isn’t necessarily bad. An experienced developer could consciously create a technical debt to unblock a project’s progress or to meet a tight deadline. In this case, the technical debt should be identified, documented, and settled (or corrected) as soon as possible,“ says Julien Bonnier, developer in the Maintenance & Evolution team.

Therefore, ’’technical debts can be directly integrated in the backlog, similar to the features to prioritize,“ explains Mathieu Fillion, Development Team Manager.

When faced with a technical debt situation, the goal is to quickly repay it to prevent “interest” accumulation. Although technical debts are inevitable in software development, they can be controlled by adopting several measures throughout the digital tool’s life cycle.

Right at the technological choices phase at the beginning of a project, it is important to keep the chosen solutions’ sustainability in mind. Indeed, technical debt can sometimes be caused by choosing a solution that is easier to develop – instead of a more adapted solution that requires more work. Thus, we must have a long-term vision to make a choice that best combines commercialization and sustainability requirements.

Because technical debts can frequently be caused by architecture or development errors, architects and developers must respect a variety of best practices to limit technical debt risks. Many processes are implemented during sprints to prevent these eventual mistakes, including the architecture review at the start of the project, or the code review for each pull request during the development phase. From a DevSecOps perspective, other very important practices are also integrated in the process: keeping libraries updated or having and keeping at hand continuous deployment pipelines to ensure quick fixes when there is a detected flaw.

’’Regularly performing updates increases software predictability and is a lot cheaper than the occasional gigantic and risky update,’’ says Charles Lévesque, developer in the de Maintenance & Evolution team.

Indeed, maintaining solutions is the ideal way to mitigate contingency risks and budget overruns.

Ultimately, the biggest technical debt is always the one that doesn’t exist – in other words, no digital solution. Even though there are development and maintenance costs, in 2022, the benefits of adopting digital tools are far superior to an inexistent system. Today, digital transformation must be a pillar in each organization that wishes to ensure its durability.